Washington 
systems 
Center 


Technical 
Bulletin 


VSAM Performance Study 
Foil Presentation with Text 


Washington Systems Center 


DAPS Code 0894 
GG22—9022—00 


: ® April 1979 


Washington Systems Center 
Gaithersburg, Maxyland 
Technical Builetin 


VSAM Performance Study 
Foil Presentation with Text 


S. E. J. Friesenborg 
T. BR. Mit¢hell 


VSAM using the ISAM Interface Program was measured and con- 
pared to native ISAM performance on 3330-1 disks and 158-1 
CPU. The major findings are part of this presentation. The 
text explains the contents of each foil. 


The prupose of the measurement runs was to quantity the 
attect on performance of the various VSAM and ISAM options 
and to provide current VSAM measurement information. 


This Technical Bulletin is being made available to IBM and 
customex personnel. It has not been subject to any formal 
review and may not be a total solution. The results 
obtained are valid only for the configuration and 
environment in which they were obtained. Similar results 
may not be achieved on other confiqurations and 
environments. 


A form is provided in the back for comments, criticisms, new 
data, and suggestions for future studies, etc. IBM may use 
or distribute any of the information you supply in any way 
it believes appropriate without incurring any obligation 


whatever. 


DAPS Code Q894 
GG22-9022-0090 
April, 1979 


TABLE OF CONTENTS 


PICU Le. PA 0 © x, cued. ar snk Serato Wi ea cw at wie SR Se 1 
OD ISCES VES 2256.4 oie Sw eS we SES eet es ee 2 
DOS EG Yk 6 Be es Se ee Se eee a a Re ee ee we 3 
DeSragn = POG raw so5 665. ee 5 BH OSE SEES AA ee eee uy 
DESiOGth = St6pS 4.4.4 .ewe nck ee a awe eh ew ce ae te ee S 5 
DESLON: = RUNS 6 «oe: 6d 2-5 he AS Oe ah GS eS 6 
DESLGM: = “Data, SACS vie 4 oie eo we See ae eee 7 
Results - Sequential Write...............2...2. 8 
Results - Sequential Read.......... 2 ee ee ee 9 
Resulus = Puls. TrACH + owe eters boa Se ees eee es 10 
Results - Buffering (Optional).............. 11 
Resuits = WRITECHECK © oo 4664 Bie Se Rew ASA wwe oS 14 
Results - Random Read... ... ee ee ee ee ee 15 
Results - Random Update..................22- 16 
Results - Random Insert... ..... 2... cee ee eee 17 
VSAM. SO i Pe CLG 6 gros alent es oe oe ele oa Se eens 18 
MiSGe1 LANG OUS 22s Soh OE EA SS ae OR Se OS 193 
CONGCLUS TONG. ci) oe 68 be os aS ee ee Re Se See ees 20 
NAT VAC S. TON TD <4 © Bee eee ere er ae See ane e 22 


Reader's Comment Form 


M 


/] 
VS 


PERFORMANCE STUDY 


WASHINGTON SYSTENS CENTER 


PAGE 


OBJECTIVES 


BOL 
® QUANTIFY 
@ CONTROL 


FER WASHINGTON SYSTEM CENTER PAGE 2 


DESIGN 


° MEASUREMENT 
3 MF 
OMI 
CREF) 


° ISGLATICON 
° INVESTIGATION 
° SPFAND-ALONE 


FEZ WASHINGTON SYSTEM CENTER Ree 


ah ae 

aero 
ad 
=F 


DESIGN 


- PROGRAM EXAMPLE 


IDENTIFICATION DIVISION. 


PROGRAM-ID. 
AUTHOR. 


RR. 
SIEBO FRIESENBSORG. 


INPUT-CUTPUT SECTION. 
FILE-CONTROL. 
SELECT ISAM-FILE, 
ASSIGN TO DA-I-ISAM, 
ACCESS MODE IS RANDOM, 


NOMINAL 
RECOR 


KEY IS N-KEY,» 


KEY IS R-KEY. 


DATA DIVISION, 

FILE SECTION. 

FD ISAMN-FILEs 
BLOCK CONTAINS 12 RECORDS» 
RECORD CONTAINS 200 CHARACTERS, 
RECORDING NODE IS F, 
LABEL RECORD IS STANDARD, 
DATA RECORD IS ISAM-RECORD. 

Ol ISAMN-RECORD. 


05 FILLER PIC AC1). 
O05 R-KEY PIC 7C8). 
O05 FILLER PEC AC192). 
WORKING-STORAGE SECTION. 
77 = N-KEY PIC 9(8). 


PROCEDURE DIVISION. 
CPEN INPUT ISAM-FILE. 
ACCEPT CARD-IMAGE FROM SYSIN. 


COMPUTE 
CALL 
LOOP. 
COMPUTE 
fr IéN2 
COMPUTE 
STATEMENTS. 
COMPUTE 
COMPUTE 
COMPUTE 
COMPUTE 
COMPUTE 
COMPUTE 


HIANT = HIAMT / INCREMENT. 


'SPIKE’. 


TZN2 = TZN * 65539. | 
IS GREATER THAN ZERO GO TO STATEMENT6. 
EZN2 = FZN2 + 2147483647 + 1. 


YFL = IZN2. 
TZNi = ITZN2. 
YFL = YFL xX 
RNDU = YFL. 
TENP RNDU * HIAMT. — 

N-KEY = INCREMENT * TEMP. 


-S4656613E-9. 


fe | 


READ ISAH-FI LE ° 
ADD 1 TO X-KEY. 
IF X-KEY IS LESS THAN OPERATNS GO TO LOOP. 


END-OF-FILE. 


CLOSE ISAM-FILE. 
MOVE 1 TO RETURN-CODE. 
STOP RUN. 


'=53 WASHINGTON SYSTEM CENTER 


PAGE 


oo0r10002 
00020002 
00030002 


00130002 
00140002 
00150002 
00160002 
00170002 
00180002 
00190002 
00200002 
00216962 
06220062 
00230013 
00240006 
00250002 
00260002 
00270002 
00280002 
00290002 
c0300002 
00310002 
00320002 
00330002 


00460002 
60470002 
00480008 
004390009 
co5c00002 
60510002 
00520003 
00530005 
00540003 
00550003 
00560003 
60570003 
00580003 
06590003 
00600009 
00610009 
00620005 
00630006. 
00640006 
00650004 
00660002 
00670012 
60680002 


DESIGN = STEPS 


TIPSW SEQUENTIAL WRITE 
CLOAD)D 

TIPSR SEQUENTIAL READ 

TIPRR RANDOFR READ 

IIPRU RANDOM UPDATE 

LIPRW RANDOM WRITE 


CINSERT) 


° ISAM VARIANTS 
CYLINDER INDEX 
TRACK AREA 
BLOCKSIZE 
OPTIMAL 


° VSAM VARIANTS 
=e age ae ae Hes 
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DESIGN - RUNS 


ISAM1 | VSAMI 
ISAMB | VSAMB| 


1 ISAMC 


| TSAMT | 


ISAM | | WRITE CHECK 


BASE CASE 


BUFFERING 


RESIDENT INDEX 


FULL TRACK 


/TSAMD | VSAMD DUMMY 


ISAMR | VSAMR| ADDRSPC=REAL 


OPT=U 


| ISAMA | | TRACK AREA 


rd VSAMA CA SPLITS 


VSAMI| CI SPLITS 


"OPTIMAL" REAL 


TOPTIMAL * 
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DESIGN - DATA SETS 


PARAMETER 


RECQRDS 
LRECL 
BLKSIZE 

KEYL 

FREE REC/CYL 
CYLINDERS 
IMBED 

BUFNO 


64 

103 
TRKX 
5 
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RESULTS - SEQUENTIAL WRITE 


=f SRB MACT EXCP CHNL 
ISAML | 203.50 | 36.58 | 11.94 | 86763 
ISAMS | 98.16 4 21.69 | 5648 | 86763 
ISAM] f 203.90 {| 36.58 | 11.94 | 86763 
LSAT | £09.38 17245 | 4.04 } 86763 


ISAML | 203.90 | 36.58 | 11.9% | 86763 | 7708 | 53.2 
| 34.85 | 12.25 | 86763 | 7797 | 51.3 


ISAMU | 195.38 


VSAMI | 379.01 
VSAMB | 143.66 


Lifis 
2631 


VSAML | 370.01 
VSAMT | 126.88 


VSAML | 370.01 ! 77.73 
VSAMRC | 311.68 | 89.37 


| ISAMOR 63.86 | 11.92 | 1.52 | 86763 | 1979 | 28.0 
TSAMO 75.96 | 20.13 | 5.83 | 86763 | 2067 | 27.7 
VSANO 234.92 | 51.43 | 3.77 | 86763 | 1143 | 66.1 
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RESULTS - SEQUENTIAL READ 
RUN ET TCB SRB XACT EXMCOP CHNHNL 
ISAM 32.37 10.73 | 86763 | 7232 | 
ISAMB 17.82 4.46 | 86763 | 1588 } 
ISAMI 184.11 32.37 10.78 86763 7232 
ISAMT 83.00 13.07 3.63 86763 | 1356 
mal __ _| 
VSAMI 57.86 11.44 | 86763 10954 
VSAMB 61.53 3.65 86763 
VSAMI 11.44 86763 
VSAMT 3.79 86763 
es ee 
ISAMOR 57.43 9.29 1.27 86763 | 1588 | 35.7 = | 
ISAMOR | 110.69 | 12.01 3.83 a6763 | 4299 | 39.3 | 
ISAMO 89.10 17.22 4.3% 86763 | 1588 | 36.7 
ISANO 125.44 21.33 9.66 86763 | 4298 29.0 : 
VSANO 74.98 | 30.76 3.08 86763 | 428 30.6 
VSAMO 80.33 31.44 3,99 S6763 | G28 35.7 : 
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- RESULTS - FULL TRACK 
RUN STEP ET TCB SRB XACT EXCP CHNL 


ISAM] 
ISANT 
ISAM1 
ISAMT 


VSAMC | 369.68 
VSANT | 126.88 
VSANC 3 222-64 
VSAMT | 95.92 


395.20 | 
425.67 


129.3 
157.4 


233.8 | 
254.5 
} 31.5 | 
|; 100.2 


ISAM] 
ISANT 


335.44 
408.08 | 


ISAM 


880.48 
ISAMT | 


127.24 


189.49 
483.30 


VSANC 
VSAMT 


188.63 
447.22 


7508 
15900 


34.0 
123.4 


W215 | 41.4 | 
24441 | 165.6 | 


VSAMC 
VSAMT 


215.82 
667.06 
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RESULTS - BUFFERING COPTIMNAL)D 


° AMOUNT OF PAGING 

° AMQUNT OF STORAGE 
"HORKEING SET 
ELAPSED TIME 


JOS WOSET ET 
A 30K 5 MIN 
B 200K 1 MIN 


WHICH TAKES MOQRE ? 
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RESULTS - BUFFERING 


ISAM - WRITE Rt] 
= READ 2O0Rt+1> 
- DEFAULT BUFNOQ=5 
VSAM = READ = WRITE 
- DEFAULT BUFNO=2 
IF PLHBFRNO<=THO THEN /% IF LESS THAN 3 BFRS, */ 
PLHRMIN=PLHBFRNO 3 /% OVERLAP UNDESIRABLE. “/ 
ELSE /* SOME OVERLAP DESIRABLE x/ 
bo; 
RHORK1 = (CAMDCINV/AMDLRECL)+EIGHT)/NINE3/% ROUND UP X/ 
RNORK3= (PLHBFRNOFONE)/THOs/% SET MINIMUM VALUE %/ 
IF RHORKI~=ZERO THEN/* IF NON-SPANNED RECORDS, */ 
PLHRMEN=RHORK3+ CC CRUORKI-ONE) * (PLHBFRNO-RNORK3) 7 RHORKL) 
ELSE /* SPANNED RECORDS xs 
PLHRMIN=RHORK3; 7% USE 1/2 THE BUFFERS x/ 
IF ANBSPEED<ON THEN /x IN SPEED CREATE? x7 
DO; /* YES, ADJUST SCHED VAL “/ 
/% CODE TO DROP DONN TO TRACK BOUNDERY */ 
END; /% END OF SPEED CREATE xs 
END; /% END OF CALCULATION x/ 


THUS - OPTIMAL RUN TO &K 
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RESULTS - BUFFERING 


al alk 


370.01 | 


READ 


EXCP!| ET 


&§ 0.49 Le2.t? 


122.38 


125.66 


135.73 


£39.80 


£39.43 


“| 86.86) 46.02 |; 322 || 
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215 |] 143.66 


WRITE 


CPU |E) CCP 


63.39 


62.79 


62.52 


61.31 


61.52 


62.33 


aan teaenedialemenneatncneminanmeieiatamelelt 


69.65 


19354 


L401 


1295 


1982 


RESULTS - WRITECHECK 


RUN STEP ET TCB SRB XACT EXCP CHNL 


| 86763 7708 53.2 | 
| 86763 8094 | 109.4 
25.71 3180 6360 | 104.8 
25.07 | 3180 6360 | 116.3 
86.13 2710 26560 | 233.8 
87.20 2710 26560 | 255.6 


ISAM] 
ISANW 


203.90 
384.06 


ISAMI 
ISANMW 


335.44 
387.17 


880.48 | 
11162.80 


ISAMI 
ISARIN 


370.01 
471.72 


303.27 
357.19 


VSAML | 473.34 | 
VSAMH | RH | 519.74 | 
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RESULTS - RANDOM READ 


RUN ET TCB SRB XACT EXCP CHNL 
54.45 28.29 4520 
39.18 25.27 | 4520 


353.71 
190.11 


42.77 
32.86 


4520 
4529 


ISAMOR | 242.31 | | ; | 78.4 
| ISAMO =| 261.22 | | 78.2 
VSAMO 197.74 | ! : | 36.9 
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RESULTS - RANDOM UPDATE 


RUN aaj TCB ORB XACT EXCP CHNL 


ISAM] 
ISAMC 


335.44 
242.26 


25.71 
23.18 


VSAMI 303.27 
VSAMNC 188.63 


ISAMOR | 223.86 | 33.90 | 3.65 
ISAMO 240.92 | 46.93 | 22.28 
VSAMO 194.64 | 33.02 | 9.09 
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RESULTS - RANDOM INSERT 


RUN ET TCB SRB XACT EXCP CHNL 


ISAM1 880.48 66.33 
ISAMC 683.76 59.82 


VSANMI 
VSANC 


473.3% 
219.23 


19364 
L215 


ISAMOR 
ISAMO 
VSANO 


512.10 
538.73 
229.10 
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SPLITTING 
CASE ET TCB SRB XACT 
NO SPLITTING | 
CI SPLITS 


CA SPLITS 


CA SPLIT + EXTENT 


Sau Ee oe 
= os we we ee 
eS anew fom eee 
= ee 
basil we ae one 
a a * Ww 
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NOTES OF USE 


e NO V=R VSAM IMPACT 


° ISAM EXCP COUNTS 


° INDEX SET STRATEGY 


° BLOCKING 
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VSAM/ISAM CONCLUSIONS 
BOTH: NOT SELF OPTIMIZING 


VSAM SEQUENTIAL DEPENDS 


° WRITE USES CPU 
° READ IS "ALRIGHT*® 
e ET IS GdoD 


VSAM RANDOM IS VERY GOOD 


e READ, UPDATE, WRITE 
° RECOURSE ON SPLITS 
° DEGRADATION ON INSERTS 


Se ewes ee, coe 
fers 


es 
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FOIL 1 
A performance study was done 
comparing ISAM to VSAM through 
This presentation will discuss 
and suggest which options help 


at the Washington Systems Center 
the ISAM Interface Program (IIP). 
the results of those measurements 
VSAM or ISAM performance. 
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FOIL 2 


The objective of the study was to quantify the affect on perform- 
ance of the various VSAM and ISAM options. In order to do this a 


specific environment was chosen which would permit 
in performance to be readily measured. A jobstream 
batch COBOL programs written for ISAM provided the 
Sired. It allowed the control necessary to isolate 
each change. The use o£ COBOL programs was thought 
the customer batch environment. 


those changes 

of single-thread 
environment de- 
the results of 
to be typical of 
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FOIL 3 


The design of the measurement technique included several elements 
to assure consistent and repeatable results. The tools used to cap- 
ture performance information were SMF, RMF, and the hardware monitor 
SMI. The jobstream was run stand-alone single-thread on a S/370 158 
model 1. | 

The base cases were run with all of the above tools as well as a 
test with a full GTF trace. The GTF trace showed the actual flow o£ 
activity which allowed us to understand several unpredicted results. 

Isolation was achieved by using single purpose programs running 
Single-thread batch in a stand-alone environment. Only one change 
at a time was made to the VSAM or ISAM options. 
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FOIL 4 


The COBOL programs used were single purpose as this example shows 
for the random read case. There was no heavy logic to distort 

the results. The programs OPENed the file, called SPIKE which; did 
a GETMAIN for all of storage, touched each page, then did a 
FREEMAIN, to allow us to measure the actual working set of the 
program instead of that of VSAM OPEN. The program then accessed the 
file uSing a random number generator, and when done, CLOSEd the 
file. To show success£ul completion based on an expected path in 
the program, a user return code of one was set. 
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FOIL 5 

There were basically five programs used.The IIP prefix stands 
for ISAM Interface Program which was used for all the VSAM runs. 
The suffix indicates the type of file access being done. 

The programs were run in the sequence you see here; | 
sequential write (load),sequential read of the entire file, 
random read, random update, random write (insert). The opt~- 
imal runs used a combination of options which were found to be 
beneficial in the isolated runs. In addition, the optimal runs 
included a second pass of sequential read, random read, random 
update, and random write programs in order to study the impact 
of degradation caused by insertion. 

Several variants of the base programs were required to implement 
the ISAM options o£: cylinder index in storage, a main storage work 
area, blocksize, and combinations of the preceeding. It is of 
note that just to change the blocksize in COBOL required a re- 
compile of all the random processing programs. Thirteen additional 
programs were created to accomodate this inflexibility. 

A special variant was written for VSAM to measure the affects of 
CA and CI splits. 
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FOIL 6 


The jobname indicates if the run is ISAM or VSAM. The suffix 
indicates the option being measured for this series of steps. 
ISAM1 and VSAM1 are the base cases, neither being particularly 


tuned. 


They are the starting point for all the options, thus 


the measured change is from this base. There is no reason to 
believe that installed ISAM or VSAM users are well tuned. 


Encoding of the jobnames is explained here. 


ISAMB 
VSAMB 
ISAMC 
VSAMC 


ISAMT 


VSAMT 


ISAMNW 
AND 
VSAMNW 


ISAMD 
AND 
VSAMD 


ISAMR 
AND 

VSAMR 
ISAMU 


ISAMA 


VSAMA 


VSANMI 


ISAMO and VSAMO 


A buffered run using a cylinder's worth of buffers. BUFNO=85 

A buffered run using a cylinder's worth of buffers.BUFND=109 
The APPLY-CORE-INDEX clause in the I-O-CONTROL section of 

the COBOL program brings the cylinder index into main storage 
Emulates cylinder index in storage by providing enough index 
buffers to hold the index set, not including the sequence set 
Is a full track buffering run achieved by specifying DCB 
BLKSIZE=12800 and changing the number of records per block 

in the program from 12 to 64. This is to test the hypothesis 
that big blocks in a virtual environment are better for 
performance. 

Uses a data CISIZE of 12288 bytes to provide a comparable 
measurement to ISAMT. 

Implements the WRITECHECK option which causes an extra ro- 
tational delay to reread the data written and check the ECC 
for a good compare.It should he noted that this does not read 
the data into the host nor does it compare the data sent with 
the data read from DASD. 

Called “DUMMY” runs since they did no file accesses. 

The program was executed, issued the OPEN, ran through the 
random number generator, and issued a CLOSE without doing 

any file access. This was done to measure the basic cost of 
executing a VSAM program. 

These jobs were run with ADDRSPC=REAL. Could VSAM run real 
and would it perform better as ISAM does ? 


This applies only to ISAM’s option during load to use OPTCD=U 
which tells the system to accumulate and write track index 
records as a group for each track of the track index. There 
is no comparable VSAM option. 

Implements the TRACK-AREA clause in the FILE-CONTROL section 
o£ the program. It causes a full track to be accumulated 
before any writes are done to the file. This option is not 
valid for load (@ISAM) processing. 

It measures the additional cost of a VSAM control area split. 
Two variations were run: 1) a CA split with no additional 
extents required and 2) a CA split with additional extents 
required. 

It measures the cost of a CI split 1) not causing 

a CA split and 2) cauSing a CA split. 

These runs were a selection of options in the 
previous runs which had improved performance notably. 


ISAMOR This is the ISAM optimal run executing V=R which is of 


particular benefit to ISAM but, not £for VSAM. 
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FOIL 7 
Here are the base case parameters either selected or defaulted 

for both ISAM and VSAM. You will notice that ISAM under MVS now 
defaults to 5 butfers, not 2. VSAM defaults to 1 index and 2 data 
butfers. One of the data buffers is set aside for record inserts. 
The size of the file is 86,763 records. Free space in VSAM was 
allocated to avoid splits for the base runs. This caused a larger 
physical file for VSAM. The VSAM option, IMBED, puts the sequence 
set portion of the index on the same cylinder as the data ( assuming 
cylinder CA'’s) it references which is most like the track index 
structure that ISAM forces on the user. 
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FOIL 8&8 
The measurement results are depicted by comparing the base run 
results against each of the several options selected. The optimal 
ISAM and VSAM runs are then compared for that type of processing. 
The headings from left to right describe the run name, the total 
elapsed time, the TCB time, the SRB time, the number of file re- 
quests made from the program, the number of EXCP’s, and channel se- 
conds. These numbers are taken from SMF except, obviously, the 
number of program requests. 

This first chart shows results for the sequential write or load 
runs. The first comparison is that of the base with the highly 
buffered, BUFNO=85, ISAM run. All factors show improvement. As 
we move on to the full track comparison a further improvement is 
shown even though large buffering is not used. The OPTCD=U has 
only slight improvement over the base case. 

The VSAM buffered run, BUFND=109, shows improvement over the base 
case although not as good as the ISAM runs. VSAM full track CI 
Size helps a little, but running VSAM recovery creates a greater CPU 
burden while using less elapsed time. The buffered run did greatly 
reduce EXCP’s. Depending on your shop’s billing routine or 
largest bottleneck, this may be to your advantage. 

From the optimal runs one can see that ISAM running real or 
virtual is a better sequential performer than VSAM. Thus one 
should not expect VSAM to be a good load performer. 

If the ISAM file load is for reorganization only, we should 
still consider using VSAM since random and sequential processing do 
not suffer greatly as the level of insertion increases. I£ the 
the ISAM load is due to application design (new records added with 
merge logic) there will be significantly more CPU time required 
by VSAM which cannot be eliminated. 
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FOIL 9 

Again for sequential read the buffered and track blocking were 
the most favorable runs. ISAM track blocking is more efficient 
than a cylinder's worth o£ buffers. VSAM did somewhat better 
reading than loading. The elapsed times are reasonable. 

Looking at the optimal runs, ISAM running real is superior. 

One must consider the scheduling problems in MVS for an 

address space running real. How many concurrent jobs could one 
schedule and how would that affect the online systems? If the 
virtual runs are compared, the second pass of the file after 

a small number of inserts show a more rapid degradation for ISAM 
in all factors, especially EXCP'’'s. 

NOTE: VSAMO equals ISAMO in CPU time if 3808 records are added 

to the file. This is 4.39 % insert level. VSAMO equals 
ISAMOR if 13745 records are inserted, a 15.8 % insert 
level on the file. (This is extrapolated data.) 

This prevents hard conclusions as to the relative performance 
of VSAM and ISAM sequential processing: each ISAM insert will 
result in an additional I/0 during sequential processing. Pointer 
logic in ISAM overflow areas prevent any CCW chaining possibi-~ 
lities. This causes rapid performance degradation for ISAM. 

VSAM sequential reads are clearly inferior to ISAM sequential 
reads against a “clean” file, but it is highly probable that 
applications are not reading "clean" files most of the time. 

One of the design objectives of VSAM was to avoid the degrad~- 
ation of inserted records. The number of EXCP's is much lower 
than any of the ISAM runs. VSAM channel utilization time is 
loner in most of the runs shown here. 
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FOIL 10 


Here are the results for full track runs. As mentioned before, 
full track blocking greatly helps performance factors both 
for ISAM and VSAM. The slower performance of VSAM prompted us to 
do some further investigation of sequential processing which will 
be discussed shortly. 

The random results for full track blocking show the expected re- 
sult in most cases. Random processing is looking for one record 
not a group of records, thus there is extra time required to 
read a larger DASD block for the DASD device reflected in longer 
elapsed time, yet there is little affect on CPU time for ISAM. 
Looking at channel utilization, both ISAM and VSAM are affected 
by the large data transfer time. 

For VSAM both CPU and elapsed time increased. This says that 
no or small blocking for random processing is a better performer 
for VSAM. The EXCP's go up as well because of additional index 
reads. 
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IBM 


In our benchmark design we had to consider the trade-off of 
additional buffers versus storage and CPU utilization. The results 
shown in preliminary runs proved that the steps took less time 
with more buffers, thus tying up storage for a shorter time. 

I£f one looks at the use of extra buffers and theizr affect on 
paging and CPU usage, what is the "working set” of this run over 
What period of time? If job A uses only 50k of storage (fewer 
data buffers) but takes 5 minutes elapsed time. It has taken the 
equivalent of 5 times 50 or 250 storage minutes. If JOB B on 
the other hand, takes 200k "working set" and runs for one min- 
ute, it has used 200 storage minutes. Which would you say takes 
more resource? 
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FOIL 12 


The sequential performance of VSAM led us into a further inves~- 
tigation. Buffering for the two access methods is different. For 
ISAM the default in MVS is now 5 buffers. Prior to MVS 3.0 it was 
2. The default for VSAM is 2 data buffers, one of which is used 
only for inserted records. How could we tune each? We needed to 
study the logic of butfer scheduling for each. | 

ISAM will use R plus one buffers for sequential writes, where R 
is the number of blocks per track specified. For read two times R 
plus one is the formula. Since five 2400 byte records £it on a 3330 
track in the optimal runs, six buffers for file load and 12 bu£t- 
fers for sequential read performed as well as the full cylinder 
buffering runs. | 

VSAM uses the same number of buffers for read as for write. In 
the VSAM code is the algorithm which follows. It schedules 
at least halt of the data buffers specified and adds to that 
quantity a £actor depending on the number of records per CI. 

As a result of this and other measurement runs, the data CI size 
was changed from 2k to 4k for the optimal runs realizing that we 
would hurt random performance but help sequential performance. 
Because of this some "“optimal™ run times will exceed those of 
earlier study runs. Please remember this on later foils. 

An installation that understands the relative importance of on- 
line random performance versus sequential batch performance 
might not make the same decision. 
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FOIL 13 


Here are some experiments with VSAM sequential buffering. The 
number of data buffers was increased up to a cylinder's worth, 
the maximum number that VSAM will chain together and schedule. 
As the number of buffers increases the number of EXCP's should 
fall and as you can see, they did. Now as we examine CPU and 
elapsed time we discover a strange phenomenon. The CPU initially 
decreases then begins to rise again as does elapsed time. Thus 


lots of buffers may not be the solution to a performance prob- 


lem. | . | 

Back to the code. For sequential as well as any other processing 
buffer look-aside is being attempted for each BUFC with every data 
butfer. This appears to account for the results. | 
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WRITECHECK measurements had predictable results. The CPU was 
not affected, but the elapsed time was due to the extra wait time 
for an additional DASD rotational delay. 
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FOIL 15 


Random results show VSAM's best side. Using in-storage cylinder 
index ISAM improves nicely. Note the number of EXCP"s for ISAM1. 
It is highly suspect that some I/O's are not being reported to 
SMF since the number of file requests equals the number o£ EXCP's. 
ISAM must at least read the track index before the data. Note 
that with cylinder index in storage the count is more realistic. 

By adding only a few (3) index buffers to VSAM: elapsed time, CPU 
time, and EXCP's are all reduced. This is a very cheap resource 
cost for a big benefit in performance. 

Inserts did not degrade the random performance of ISAM or VSAM 
in this study because of their even distribution throughout the 
file. There was never more than first-in-overflow for the ISAM 
file. This is not thought to be typical. 


The optimal runs show VSAM an elapsed time Winner against ISAM 


running real and a definite winner against ISAM virtual's best 
options. VSAM channel usage is much more frugal than ISAM. 
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Here are the random update runs. The results are very similar to 


the random read results. The VSAM optimal run CPU total is closer 
to the ISAM real CPU total. (SRB +TCB) Again EXCP count is off 
for ISAM. Note the VSAM channel time here as well. 
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VSAM is again a very good performer during random 


versus the ISAM optimal running real. It should be. 


level of inserts is relatively small (3%) and that 
number generator uniformly distributed the records 
to not cause more than first-in-overflow records. 


inserts, even 
noted that the 
the random 

so evenly as 
Since customers 


do reorganize their ISAM files frequently, we feel that our 


insert level is not typical. 
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As one adds records to a VSAM file there exists the possibility 
of creating a CI split which in turn may require a CA split in 
order to complete. What does that cost? Should splits really be 
avoided? Our project design avoided splits because we did not 
know how many splits are "“"represenative”. 

The base run was set up to cause no splits. This is felt to be 
a reasonable approach. We think that in the customer environment 
which reruns the same file load many times, their experience can 
help them avoid CI/CA splits. 

The next line shows the unit cost of doing only a CI split, 
ie. there was a free CI in the CA. There is some cost but it 
is minimal. The next run caused CA splits within existing 
file extents,ie. the £ile was defined with extra space. This is 
a much heavier cost. The worst case is a CA split causing VSAM to 
go to the catalog to acquire secondary suballocation. This is much 
worse than any of the previous tests. Notice the number of EXCP'’s 
that are used in this environment for a single request. 

In summary, CI splits within a CA cost very little additional 
overhead but, CA splits, especially those requiring additional 
extents should be avoided. There is feedback available in the 
catalog and SMF records for a user to determine his split level 
and adjust the file freespace. These results show you how concerned 
you should be about each type of split. 
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Some miscellaneous comments should be made about the runs. 
VSAM running real has no advantage, but it does run real. 
ISAM EXCP counts may not be valid so comparisons in the 
customer shop should note that fact as it applies. 

It makes no significant CPU difference if the VSAM data set 
has 2 or 3 index levels if the index set is kept resident. 
This is because of a very fast VSAM index search algorithn. 
BlocKing is not the answer to performance problems, especially 
in the online environment (random processing). 
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After all these measurements and investigations there are some 
conclusions one can define. Neither ISAM or VSAM is selt-optimizing, 
ie. defaults are not the best performance options. Design is re- 
quired. It is hard to come to any other conclusion when runs on 
the same data produce double or triple run times depending on the 
options selected. 

Sequential performance depends on usage. If the file is loaded 
frequently, the results for VSAM will be elongated. Read perform- 
ance will pass but, the buffer look-aside hurts thruput. The 
elapsed time is good. 

VSAM random performance is outstanding even when compared to 
a well-tuned ISAM running virtual=real. CI/CA splits are not 
desirable but, can be tuned to take the least costly option 
in terms of CPU and EXCP's. ISAM has increasing and rapid 
degradation as the level of inserts increases for all types of 
processing. VSAM was specifically designed to avoid this degra-~ 
dation. 
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This study has shown many definite performance advantages 
o£ VSAM over ISAM even though there has been no discussion 
o£ £unctional capability differences. For an online response 
oriented system VSAM is the answer. 
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